The present invention relates to routing transactions within a network environment. More specifically, the present invention relates to the routing of transactions within a network environment using a virtual transactional processing center.
Transaction processing systems (TPS), such as, for example, automatic call distributors (ACDs), are typically used in transactional service systems to provide for the automatic routing of incoming transactions, such as telephone calls or other transactions, to an appropriate or select destination based upon information associated with the incoming transaction.
Currently, transactional service systems, which may, for example, comprise a series of ACDs interconnected through a series of communication links between the respective ACDs, along with a central processing office, have limited resources with respect to the efficient routing of transactions within the transactional service system.
In an exemplary prior art transactional service system 100, as illustrated in FIG. 1, an incoming transaction 102 (e.g., phone call) is received by a central processing office 104 that identifies the request associated with the incoming transaction 102 and directs the incoming transaction 102 to an ACD 106 designated to service such a transaction 102. Accordingly, the transaction 102 is routed to the selected ACD 106 (original ACD) for eventual servicing by a qualified transaction agent 108 associated with the selected ACD 106. The transaction agents 108 associated with a particular ACD 106 may not be immediately available to service the transaction 102, therefore, the transaction 102 may be placed into an associated queue 110 awaiting service by the transaction agents 108.
In order to ensure that the transaction 102 does not remain within the queue 110 for an unacceptable service period, the transactional service system 100 may implement a specified quality of service (QoS) parameter. The quality of service parameter assists in monitoring the service period by essentially time stamping or time tracking the incoming transaction 102 and comparing the time stamp against an acceptable or standard service period. Accordingly, if the in-waiting service period (i.e., time period which the transaction waits until actual servicing) is within an acceptable range, as compared to the acceptable service period, the transaction 102 remains in the queue 110 to await service by a transaction agent 108 associated with the particular ACD 106 containing the queue 110. Otherwise, if the in-waiting service period violates an acceptable range, as compared to the acceptable service period, the transaction is typically transferred to another ACD 112 (transfer ACD), via the communication link 114, in order to be serviced by another transaction agent 118 associated with the transfer ACD 112.
Likewise, the transaction agents 118 associated with the transfer ACD 112 may not be immediately available to service the transaction 102, therefore, the transaction 102 may be placed into a second queue 116, associated with the transfer ACD 112, to await service by a transaction agent 118. Accordingly, the transaction 102 placed into the transfer ACD queue 116 is still awaiting service by a transaction agent 118, while the customer or originator of the transaction 102 waits to speak or interact with the next available transaction agent 118. Ideally, a transaction agent 118 associated with the transfer ACD 112 is able to service the transaction 102 within the desired acceptable service period.
Provided a qualified transaction agent 118 associated with the transfer ACD 112 is able to service the transaction 102, two separate communication links are necessary to support the servicing of the transaction 102, a first communication link from the central processing office 104 to the original ACD 106, and a second communication link from the original ACD 106 to the transfer ACD 112.
If a qualified transaction agent 118 associated with the transfer ACD 116 is unable to service the transaction 102, the transaction 102 may have to be sent back to the original ACD 106 which originally received the transaction 102. As a result, three separate communication links would be necessary to support the servicing of this transaction 102. The three communication links would consist of a first communication link from the central processing office 104 to the original ACD 106, a second communication link from the original ACD 106 to the transfer ACD 112, and a third communication link from the transfer ACD 112 back to the original ACD 106. This triple routing over communication link 114 is sometimes referred to as a xe2x80x9ctrombonexe2x80x9d.
One solution that has been offered in response to such redundant multiple routing problems is the employment of a transfer connect service. The transfer service allows for the reduction of redundant multiple routing problems by eliminating the redundant communications lines and providing the transaction to the final selected service location in response to a request generated by the transactional service system 100. For instance, once the final selected service location is determined, the transactional service system 100 sends a request to the central processing office 104 to route the communications line directly from the central processing office 104 to the final selected service location, if possible. This solution provides an xe2x80x9cafter-the-factxe2x80x9d solution to the problem of redundant multiple routing, which in turn requires additional service costs the operator of the transactional service system 100. The additional costs are not only in terms of monetary costs to implement such a service, but also in terms of resources being expended to initially support the usage of unnecessary communication lines in the first place.
As illustrated by the above transaction routing examples, a standard transaction serviced by the typical transactional service system may require excessive system resources or other costs to be expended in response to the routing of a transaction. As such, the typical transactional service system may suffer from the inefficient routing of transactions within the system. This inefficient routing of transactions within transactional service systems wastes system resources and results in increased costs associated with operating the system. As previously illustrated, the transaction can be subject to multiple transfers between ACDs which costs the operator of such transactional service systems both time and money. As such, a transaction which has been subjected to multiple routings between the ACDs may be forced to the next available transaction agent in order to service the transaction within a particular service period regardless of whether the particular agent has the proper qualifications to handle the transaction.
An embodiment of the present invention provides for a method and apparatus for routing a transaction. Initially, a resource is identified which is capable of servicing a transaction based upon resource data indicative of the capabilities of resources associated with a transactional processing system and a transaction request indicative of a request associated with the transaction. Upon identifying the resource capable of servicing the transaction, the transaction is supplied to the identified resource.
Another feature of the present invention provides for reserving the resource after determining the resource capable of servicing the transaction.
Yet another feature of the present invention provides for generating a routing message based upon the reservation response, the routing message indicating the identity of reserved resource.
Further, another feature of the present invention provides for supplying the transaction to the reserved resource based upon the routing message.